Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0055/539.txt

Text File | 1997-04-16 | 14KB | 327 lines

INFO-ATARI16 Digest         Fri, 20 Oct 89       Volume 89 : Issue 539

Today's Topics:
                               ⇦Turbo-C
                   Calendar Layout Around the World
                 Hey Borland, why no Turbo C for US?
                             Link format
   Malloc - what it really does (was: Re: SPUFILE 2.0, C questions)
                            PROGRAM COSTS
               REFILLING HP DeskJet Cartridges cont...
                              ST in USSR
            TOS 1.4, memory chips, T16...and the Mega2 STs
                               Turbo C
----------------------------------------------------------------------

Date: Fri, 20 Oct 89 13:09:43 MEZ
From: [e-mail] (Julian Reschke)
Subject: ⇦Turbo-C

Just to clarify the situation: the menus of TURBO-C ARE english! Only
documentation and online-help are in German. Perhaps some publishing
company should offer an english documentation for Turbo-C?

                                                Julian Reschke


------------------------------

Date: 20 Oct 89 06:17:31 GMT
From: mcsun!sunic!tut!tukki![e-mail]  (Timo Suhonen)
Subject: Calendar Layout Around the World

In article <[e-mail]> [e-mail] () writes:

>I have another question, about calendars:  which day should be in the
>leftmost column?  Is Sunday always in the leftmost column everywhere?  Is
>Sunday always in the leftmost column in the USA?  If the answer is no -
>which other day(s) should be in the leftmost column:  Monday? Just
>Monday?
Al least in Finland Monday is the leftmost column.

Timo
--
Timo Suhonen                                           [e-mail]
Disclaimer: The text above is from my left brain cell. The right one is for
          SeX and Drugs and Rock'n Roll. Al K. Hall has eaten the others...

------------------------------

Date: 20 Oct 89 06:14:38 GMT
From: mcsun!sunic!tut!tukki![e-mail]  (Timo Suhonen)
Subject: Hey Borland, why no Turbo C for US?

In article <[e-mail]> [e-mail]
 (Tom Limoncelli) writes:

>is second rate... or at least it doesn't meet "American standards".
What are these American standards??


Timo
--
Timo Suhonen                                           [e-mail]
Disclaimer: The text above is from my left brain cell. The right one is for
          SeX and Drugs and Rock'n Roll. Al K. Hall has eaten the others...

------------------------------

Date: 19 Oct 89 07:02:40 GMT
From: mcsun!unido!tub!tmpmbx!netmbx![e-mail]  (Hartmut Semken)
Subject: Link format

In article <[e-mail]> [e-mail] (Daniel Deimert) writes:
>And I think that MWC can produce DRI format files, but I'm not sure.

No. It can convert them to MWC format. A one way ticket.

>Maybe Alcyon C?

Yes. The DRI C compiler does produce DRI object files, indeed.

hase
--
Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 [e-mail]
Dennis had stepped up into the top seat whet its founder had died of a
lethal overdose of brick wall, taken while under the influence of a
Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...)

------------------------------

Date: 20 Oct 89 08:21:34 GMT
From: mcsun!unido!laura!trillian.irb![e-mail]  (Rainer Klute)
Subject: Malloc - what it really does (was: Re: SPUFILE 2.0, C questions)

In article <[e-mail]> [e-mail] (Ray Wallace)
 writes:
>In article <[e-mail]>, [e-mail] writes...
>>      1) Does Malloc(-1L) not work properly?
>This only returns the size of the largest chunk of free memory. So if you have
>holes in your free memory (non-contiguous) then it will return a number
>smaller than the total of all free memory.

From what I have found out Malloc (-1L) returns the *sum* of the
sizes of *all* free memory chunks. So, what you should not do
without further checking is as follows:

        buffer_size    = Malloc (-1L);
        buffer_address = Malloc (buffer_size);

This will not work as intended because the second Malloc will
result in a pointer to the largest available chunk only, not to
all the free memory, because the latter is not neccessarily
contingous! So the buffer located at 'buffer_address' does not
have a size of 'buffer_size' but of some smaller value. The
real buffer size you can estimate by adding another statement
to those above:

        real_buffer_size = buffer_size - Malloc (-1L);

Disclaimer: I still use TOS 1.0.

  Dipl.-Inform. Rainer Klute      [e-mail]
  Univ. Dortmund, IRB             [e-mail], [e-mail]
  Postfach 500500         |)|/    ...uunet!mcvax!unido!klute
D-4600 Dortmund 50        |\|\    Tel.: [phone]

------------------------------

Date: 20 Oct 89 02:58:09 GMT
From: emcard!wa4mei!kd4nc!km4ba![e-mail]  (Alan Barrow)
Subject: PROGRAM COSTS

In article <[e-mail]> [e-mail] (David
 Harrison) writes:
>
>Generalising these numbers, we might conclude that it is people who
>think good software should cost less the $100 that are "just plain ..."
>--

Actually, I conclude that the problem lies with the way Lotus wrote their
software..... They welded the sw to the HW platform, which not only made
ports difficult, but helped make "compatibility" into the curse of the PC-DOS
world. ( 100 man-years to port is the price you pay for squeezing that
extra bit of performance out of IBM's sluggard son)

Even Lotus's current products show the old school attitude when compared
to Excel & others.. ( I canned Lotus at 2.0? ) Excel is virtually device
independant compared to lotus. I have no sympathy for applications that insist
on reinventing the user interface. It will prob be running on 4 or more O/S
( Including unix ) while lotus is still working on the latest rev. for dos.


Not that Excel is the perfect sw package (Just better than most :->), but
in most cases, the more rules (O/S, bios, etc) you break, the more trouble
you will have porting.... (every programmer knows this, we just do it anyway!)

So.... I *do* believe that good sw can be cheap & portable!
(and *no*, I do not work for a SW company :-> )

>David Harrison                            | "God does not play dice with
>Dept. of Physics, Univ of Toronto         |  the universe." -- Einstein
>UUCP: uunet!attcan!utgpu!utfyzx!harrison  | "Quit telling God what to
>BITNET: HARRISON@UTORPHYS                 |  do." -- Niels Bohr

Alan Barrow                     "I am not a computer person......
..!gatech!kd4nc!km4ba!alan                 but I play one on TV......"

------------------------------

Date: 20 OCT 89 08:53:20 CST
From: Z4648252 <[e-mail]>
Subject: REFILLING HP DeskJet Cartridges cont...

    It was mentioned that a cartridge was brought back to life which
was totally exhausted, i.e., no ink at all, totally dry.  The author
mentioned that he was under the impression that such cartridges were
previously mentioned to be poor candidates for "recharging" due to
air pockets on the sponge, etc.  His efforts, the removal of the top,
I believe and the washing out of the sponge resulted in his cartridge
coming back to life.
    Ok....  the reason that I mentioned, several months back, that
exhausted cartridges were poor candidates was that they tend to be
'confused' on their siphon effect.  Certain areas on the sponge
will be dry while other areas will be wet.  This condition will remain
even when two ounces of ink have been added.  Due to the concentration
of ink in certain areas, a "track" will form providing a quick access
way to the nozzles.  The user ends up getting a dripping effect.
    Really working with a dry cartridge by removing the top and washing
out the sponge will get rid of the dry areas, thus killing the siphon
effect.  The cartridge will be restored.
    As always, such restoration attempts involve some risk.  The
cartridge is not "meant" to be restored and the nozzles have a certain
life cycle.  Also, ink from a brand relatively unknown should never be
used.   Hewlett Packard does not endorse (major understatement)
the refills, i.e., poor quality ink will result in crusting, thus
clogging up the priming tube.
    Restoration of these expensive cartridges will extend their life
considerably.  I've been on the same cartridge for several months.

Larry Rymal:  |East Texas Atari 68NNNers| <[e-mail]>

------------------------------

Date: 20 Oct 89 06:30:35 GMT
From: mcsun!sunic!tut!tukki![e-mail]  (Timo Suhonen)
Subject: ST in USSR

In article <[e-mail]> [e-mail] (Peter Bechtold) writes:
>In article <[e-mail]> [e-mail] (Markku M?enp??) writes:
>
>
>I can't imagine that the USSR would by ANY computers for their schools within
>the next 5 or 10 years.
They DO have IBM-compatibles in (technical)schools. At the time I bought my
520ST (In the early 1986), you weren't allowed to sell a ST to USSR. I think
it was because of the Motorola prosessor. At that time it was too much 'high-
tech'...

Timo

--
Timo Suhonen                                           [e-mail]
Disclaimer: The text above is from my left brain cell. The right one is for
          SeX and Drugs and Rock'n Roll. Al K. Hall has eaten the others...

------------------------------

Date: 19 Oct 89 06:52:50 GMT
From: mcsun!unido!tub!tmpmbx!netmbx![e-mail]  (Hartmut Semken)
Subject: TOS 1.4, memory chips, T16...and the Mega2 STs

In article <[e-mail]6> [e-mail] (Z4648252)
 writes:
>1.  What memory chips should be used for upgrading the ST2 to a ST4
>    if used with the T16?

1-Megabit chips (51 1000, 41 1000) with 120 or 150 nanosecond access
time; do not worry about "page mode" or "nibble mode" types: these are
special, faster read/write modes for the RAMs, that are not used by the
ST MCU. Any type should support the "standard" read/write cycle.

The ST timing is made for 150 ns RAMs. Faster RAMs may cause problems:
the faster the RAM chip can produce/take data (read/write cycle), the
faster it must go from "power down" state (about 30 to 40 Milliwatts) to
"power up" state (around 300 Milliwatts). This means, the suppy current
has to jump from <8 mA to ?60 mA; this leads to voltage drops on the
power lines (the faster the jump, the less power left for the RAM...)
The 1985 Rev. C 520 ST+ did not cause a lot of trouble when the
capacitators for each RAM were replaced with 200 nanofarads.

If You want to "recycle" the RAM chips for a new machine (there *will*
be another computer in Your life!), get fast chips (70 nanosecond) and a
bag of 200 nF capacitators; solder the capacitators between Vcc and Vss
under the RAM socket (on solder side of the PCB); if it does not work,
solder a second capacitator to every RAM chip; this gives 400 nF per chip
and should be all You need.

>2.  Should the chipped TOS 1.4 be transferred to fast EPROMS to gain
>    maximum results from the T16?

Well, the fastest bus cycle of the 8 MHz 68000 MPU is about 250
nanoseconds long (do not have the specs at hand, maybe its a little
less), so the acces of 250 ns ROM/EPROM does not require "wait states"
(think about a loop, that fills all registers from memory; with "no
wait" the MPU speed is the limiting factor, not the memory speed).
However, the 16 MHz MPU is twice as fast; if the memory can produce/take
data at the doubled speed, You'll get no wait states, too. Of course a
faster ROM is necassary to handle this speed.
200 ns ROMs/EPROMs will do it with a little trick: the acces time of
EPROMS is measured from the activation of -CE (Chip Enable, low active):
250 ns after -CE the data outputs will be valid.
You can think of -CE controling a large transistor that switches the
power to the chip on and off; disabled, the chip is sleeping (and taking
less power, producing less heat), -CE awakes it.
Now, there is another control input, called -OE (Output Enable). This
one enables the output drivers of the (awake) chip. If the chip is held
awake (-CE constant low), the acces time (after activation of -OE) is a
lot (!) faster than nominal speed. Its less than half the nominal acces
time.
The chip is now twice as fast: it can catch up with a MPU, that is twice
as fast.

The faster adress decoding and timing is - of course - not handeled by
the ST chip set. The accelerator board has to provide the new control
lines.

>3.  Should the Atari blitter be replaced with the newer?
Hmm. Terra incognita, data input required. :-)


hase
--
Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 [e-mail]
Dennis had stepped up into the top seat whet its founder had died of a
lethal overdose of brick wall, taken while under the influence of a
Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...)

------------------------------

Date: 20 Oct 89 11:07:42 GMT
From: mcsun!hp4nl!dutrun![e-mail]  (Robert de Vries)
Subject: Turbo C

In article <[e-mail]> ardvar![e-mail] (Kent
 Schumacher) writes:
[... stuff deleted ...]
>Does it have a built in editor, or are you allowed
>to substitute your own (without an unacceptable loss of features).
It is has a built-in editor, but I don't know if you can substitute your own.
I don't think so at least.
>Is it a CLI environment (like MWC) or a GUI.
Both.
>If it has a build in editor, is it gem based, does it allow marking blocks
>with the mouse (like Laser C), does it allow multiple windows, macros, ...?
It is GEM-based, you can mark blocks with your mouse, multiple windows, no
macros.
>(Oh, yeah - any comment on the documentation and 'ANSI-ness' of the compiler
>would be appreciated).
Full fledged ANSI. I love it.

     Robert.

------------------------------

End of INFO-ATARI16 Digest V89 Issue #539
*****************************************
=========================================================================